home *** CD-ROM | disk | FTP | other *** search
- RFC 778
-
-
-
- DCNET Internet Clock Service
- D.L. Mills, COMSAT Laboratories
- 18 April 1981
-
-
- Introduction
-
- Following is a description of the Internet Clock
- Service (ICS) provided by all DCNET hosts. The service,
- intended primarily for clock synchronization and one-way
- delay measurements with cooperating internet hosts, is
- provided using the Timestamp and Timestamp Reply messages of
- the proposed Internet Control Message Protocol (ICMP). In
- addition, in order to maintain compatability with present
- systems, this service will be provided for a limited time
- using the Echo and Echo Reply messages of the
- Gateway-Gateway Protocol (GGP).
- It should be understood that ICMP and GGP datagrams are
- normally considered tightly bound to the Internet Protocol
- (IP) itself and not directly accessable to the user on a
- TOPS-20 system, for example. These datagrams are treated
- somewhat differently from user datagrams in gateways and
- DCNET hosts in that certain internal queueing mechanisms are
- bypassed. Thus, they can be a useful tool in providing the
- most accurate and stable time reference. The prime
- motivation for this note is to promote the development of
- this service in other internet hosts and gateways so that
- the feasibility for its use thoughout the community can be
- assessed.
-
- ICS Datagrams and Timestamps
-
- At present, the ICS is provided using either ICMP or
- GGP datagrams. The only difference between these is that
- ICMP uses protocol number 1 and GGP uses protocol number 3.
- In the following these will be referred to interchangably as
- ICS datagrams. ICS datagrams include an internet header
- followed by an ICS header in the following format:
-
- DCNET Internet Clock Service PAGE 2
-
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Sequence |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Originate Timestamp |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Receive Timestamp |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Transmit Timestamp |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- ICS Datagram Format
-
- The originator fills in all three timestamp fields just
- before the datagram is forwarded to the net. Each of these
- fields contain the local time at origination. Although the
- last two are redundant, they allow roundtrip delay
- measurements to be made using remote hosts without
- timestamping facilities. The "Type" field can be either 8
- (GGP Echo) or 13 (ICMP Timestamp). The "Code" field should
- be zero. The "Sequence" field can contain either zero or an
- optional sequence number provided by the user. The length
- of the datagram is thus 36 octets inclusive of the 20-octet
- internet header and exclusive of the local-network leader.
-
- The host or gateway receiving an ICS datagram fills in
- the "Receive Timestamp" field just as the datagram is
- received from the net and the "Transmit Timestamp" just as
- it is forwarded back to the sender. It also sets the "Type"
- field to 0 (GGP Echo Reply), if the original value was 8, or
- 14 (ICMP Timestamp Reply), if it was 13. The remaining
- fields are unchanged.
-
- The timestamp values are in milliseconds from midnight
- UT and are stored right-justified in the 32-bit fields shown
- above. Ordinarily, all time calculations are performed
- modulo-24 hours in milliseconds. This provides a convenient
- match to those operating systems which maintain a system
- clock in ticks past midnight. The specified timestamp unit
- of milliseconds is consistent with the accuracy of existing
- radio clocks and the errors expected in the timestamping
- process itself.
-
- Delay Measurements
-
- Delay measurements can be made with any DCNET host by
- simply sending an ICS datagram in the above format to it and
- processing the reply. Let t1, t2 and t3 represent the three
- timestamp fields of the reply in order and t4 the time of
- arrival at the original sender. Then the delays, exclusive
- of internal processing within the DCNET host, are simply
- (t2 - t1) to the DCNET host, (t4 - t3) for the return and
-
- DCNET Internet Clock Service PAGE 3
-
-
-
- (t2 - t1) + (t4 - t3) for the roundtrip. Note that, in the
- case of the roundtrip, the clock offsets between the sending
- host and DCNET host cancel.
-
- Although ICS datagrams are returned by all DCNET hosts
- regardless of other connections that may be in use by that
- host at any given time, the most useful host will probably
- be the COMSAT-WWV virtual host at internet address
- [29,0,9,2], which is also the internet echo virtual host
- formerly called COMSAT-ECH. This virtual host is resident
- in the COMSAT-GAT physical host at internet address
- [29,0,1,2], which is connected to the ARPANET via the COMSAT
- Gateway, Clarksburg SIMP and a 4800-bps line to IMP 71 at
- BBN. The roundtrip delay via this path between the
- COMSAT-GAT host and the BBN Gateway is typically 550
- milliseconds as the ICS datagram flies.
-
- As in the case of all DCNET hosts, if the COMSAT-WWV
- virtual host is down (in this case possible only if the
- Spectracom radio clock is down or misbehaving) a "host not
- reachable" GGP datagram is returned. In unusual
- circumstances a "net not reachable" or "source quench" GGP
- datagram could be returned. Note that the references to
- "GGP" here will be read "ICMP" at some appropriate future
- time.
-
- Local Offset Corrections
-
- All DCNET timestamps are referenced to a designated
- virtual host called COMSAT-WWV (what else?) with internet
- address [29,0,9,2]. This host is equipped with a Spectracom
- radio clock which normally provides WWVB time and date to
- within a millisecond. The clock synchronization mechanism
- provides offset and drift corrections for other hosts
- relative to this host; however, offsets up to an appreciable
- fraction of a second routinely occur due to the difficulty
- of tracking with power-line clocks in some machines. A
- table of the current offsets can be obtained using the
- following procedure.
-
- 1. Connect to COMSAT-GAT host at internet address
- [29,0,1,2] using TELNET and local echo.
-
- 2. Send the command SET HOST HOST. A table with one line
- per DCNET host should be returned. Note the entry under
- the "Offset" column for the WWV host. This contains the
- offset in milliseconds that should be added to all
- timestamps generated by either the COMSAT-GAT or
- COMSAT-WWV hosts to yield the correct time as broadcast
- by WWVB.
-
- 3. Send the command SET WWV SHOW. A summary of datagram
- traffic is returned along with an entry labelled "NBS
-
- DCNET Internet Clock Service PAGE 4
-
-
-
- time." The string following this is the last reply
- received from the Spectracom unit in the format:
-
- <code> DDD HH:MM:SS TZ=00
-
- where <code> is normally <SP> in case the WWVB signal is
- being received correctly or ? in case it is not. The
- DDD represents the day of the year and HH:MM:SS the time
- past UT midnight. The two digits following TZ=
- represent the time zone, here 00 for UT.
-
- 4. Close the connection (please!).
-
-
- REFERENCES
-
- [1] ICMP
-
- Postel, J., "Internet Control Message Protocol", RFC 777,
- USC/Information Sciences Institute, April 1981.
-
- [2] GGP
-
- Strazisar, V., "How to Build a Gateway", IEN 109, Bolt
- Beranek and Newman, August 1979.
-
- DCNET Internet Clock Service PAGE 5
-
-
-
- Following is a specification of the ICS header in PDP11
- code:
-
- ;
- ; GGP/ICMP Header
- ;
- . = 0
- GH.TYP: .BLKB 1 ;Message type
- GC.RPY = 0 ;Echo reply
- GC.UPD = 1 ;Routing update
- GC.ACK = 2 ;Positive acknowledgment
- GC.DNR = 3 ;Destination unreachable
- GC.SQN = 4 ;Source quench
- GC.RDR = 5 ;Redirect
- GC.ECH = 10 ;Echo
- GC.STA = 11 ;Net interface status
- GC.NAK = 12 ;Negative acknowledgment
- GC.TIM = 15 ;Timestamp
- GC.TRP = 16 ;Timestamp Reply
- GH.COD: .BLKB 1 ;Message code
- GH.SEQ: .BLKW 1 ;Sequence number
- GH.HDR = . ;Beginning of original
- ;internet header
- GH.ORG: .BLKW 2 ;Originating timestamp
- GH.REC: .BLKW 2 ;Received timestamp
- GH.XMT: .BLKW 2 ;Transmitted timestamp
- GH.LEN = . ;End of timestamp header
-
- Note that all PDP11 word fields (.BLKW above) are
- "byte-swapped," that is, the order of byte transmission is
- the high-order byte followed by the low-order byte of the
- PDP11 word.
-